Walkthrough

This PR implements dynamic reloading of OAuth and account state during request retries to fix stale authentication in already-open sessions. The plugin now detects when zero accounts or maximum rate-limits are reached, attempts to reload the latest state from disk via reloadProviderState(), clears in-memory tracking maps (rate limits, toasts, failures), and retries the request instead of immediately failing. Additionally, the x-goog-api-key header is removed from Antigravity requests to avoid project-mismatch errors. Supporting changes fix account storage merge semantics to preserve empty rateLimitResetTimes objects, allowing stale rate-limit state to be cleared on disk-state refresh.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Additional Context

The changes address the root cause documented in the linked issue: already-open sessions retain stale in-memory account and rate-limit state even after disk state changes. The solution introduces a provider-state reload + retry pattern similar to OpenCode's core auth recovery flow, along with proper storage merge logic to handle rate-limit reset time clearing.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Additional validation detail from my local repro:\n\n- I reproduced this with an already-open tmux-backed OpenCode TUI session, not just fresh opencode run processes.\n- Before the fix, changing antigravity-accounts.json on disk could leave the open session stuck on stale provider/account state until restart.\n- With the patch, the same open session can continue serving prompts after disk state changes that previously required a restart.\n\nOne local-only note: on my machine, real OpenCode runs load the package from ~/.cache/opencode/node_modules/opencode-antigravity-auth, which is why I first hit the problem there before porting the fix cleanly into source for this PR.

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Review Summary:

The PR implements three related fixes:

1. Stale state reload at request time (src/plugin.ts): The plugin now reloads AccountManager from disk before each request and has retry logic when encountering stale "no accounts" or "all rate-limited" states. This fixes the issue where already-open sessions would get stuck until restart.

2. x-goog-api-key removal (src/plugin.ts): Properly strips the Google API key from Antigravity OAuth request headers to prevent unrelated Google API keys from causing project mismatch failures.

3. rateLimitResetTimes preservation (src/plugin/accounts.ts, src/plugin/storage.ts): Ensures empty rateLimitResetTimes objects are saved to disk and merged correctly, allowing stale rate limit clearing to persist.

All changes are well-tested with new test coverage for the merge and save behaviors. The code follows existing patterns in the codebase and addresses the failure modes described in the PR.

_{Reviewed by minimax-m2.5-20260211 · 414,943 tokens}

Greptile Summary

This PR fixes stale Antigravity provider state in already-open sessions by reloading AccountManager from disk on every fetch call and adding a one-shot retry via reloadProviderState for the two concrete failure modes: No Antigravity accounts available and All accounts rate-limited. It also fixes a config-leak bug where x-goog-api-key from an unrelated Google provider could bleed into Antigravity OAuth requests, and tightens the rateLimitResetTimes persistence semantics so that explicitly clearing limits on disk is not silently merged back.

Key changes:

• src/plugin.ts: accountManager changed from const to let and reloaded from disk at the start of every fetch invocation; reloadProviderState fires once per request for stale no-account / all-rate-limited conditions; x-goog-api-key stripped from both the warmup and main request headers.
• src/plugin/accounts.ts: saveToDisk now serialises rateLimitResetTimes as {} when empty (instead of omitting the key), giving mergeAccountStorage a signal to clear rather than preserve stale limits.
• src/plugin/storage.ts: mergeAccountStorage exported and updated with a three-way semantic — undefined preserves existing, {} clears to undefined, non-empty object union-merges.
• Tests: new coverage for both the saveToDisk persistence fix and the mergeAccountStorage three-way merge semantics.

Confidence Score: 4/5

• Safe to merge; the two P2 observations (disk read per request, global state clear on retry) are known trade-offs rather than correctness issues.
• The fix is well-scoped, correctly targeted at the two described failure modes, and backed by tests that exercise the new semantics end-to-end. No logic or syntax bugs found. The two P2 comments flag a shared-state mutation during concurrent retries and an unconditional per-request disk read, both of which are acceptable trade-offs for the rare recovery path.
• src/plugin.ts — the shared closure-state clear in reloadProviderState and the eager per-request disk reload are worth a second look if request concurrency becomes significant.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant C as Caller
    participant F as fetch()
    participant D as Disk (AccountManager)
    participant L as retry loop

    C->>F: request
    F->>D: loadFromDisk(latestAuth)
    D-->>F: fresh accountManager

    F->>L: enter while(true)
    L->>L: accountCount === 0?

    alt no accounts → reload once
        L->>D: reloadProviderState("no-accounts")<br/>getAuth() + loadFromDisk()
        D-->>L: reloaded accountManager<br/>clears rateLimitState / emptyResponse / accountFailure maps
        L->>L: continue (retry loop)
        L->>L: accountCount still 0?
        L-->>C: throw "No Antigravity accounts available"
    else accounts available
        L->>L: select account, prepare request
        L->>L: strip x-goog-api-key from headers
        L->>C: fetch(prepared.request, requestInit)
        C-->>L: response
    end

    alt all-rate-limited AND waitMs > maxWaitMs → reload once
        L->>D: reloadProviderState("all-rate-limited:family")<br/>getAuth() + loadFromDisk()
        D-->>L: reloaded accountManager<br/>clears shared state maps
        L->>L: continue (retry loop)
        L->>L: still rate-limited?
        L-->>C: throw "All N account(s) rate-limited"
    end

This is a comment left during a code review.
Path: src/plugin.ts
Line: 1488-1492

Comment:
**Clearing shared state affects concurrent in-flight requests**

`rateLimitStateByAccountQuota`, `emptyResponseAttempts`, `accountFailureState`, `rateLimitToastShown`, and `softQuotaToastShown` are all closure-level variables shared across every concurrent request in the same plugin instance. When one request triggers `reloadProviderState`, these maps are cleared globally, which means any other request that is mid-flight at the same moment loses its accumulated per-attempt tracking (e.g. backoff state, empty-response counters).

In practice the reload path is rare and the worst case is that a concurrent request retries against a previously-known rate-limited account once before re-discovering the limit. This is unlikely to be noticeable, but it's worth noting that the clear is not scoped to the triggering request.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/plugin.ts
Line: 1464-1465

Comment:
**Disk read on every request**

`AccountManager.loadFromDisk` is now called at the top of every `fetch` invocation, unconditionally. For heavy workloads (e.g. many parallel tool-call requests in a single agent turn) this multiplies disk reads proportionally. 

Since the intent is only to avoid staleness between user interactions, it could be worth debouncing or caching the result for a short window (e.g. 1–5 s) so that a burst of concurrent requests within the same turn shares one disk read. This is not a correctness issue, but it may become noticeable at scale.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(plugin): reload stale provider state..." | Re-trigger Greptile}